パフォーマンス最適化

• コントローラーのプロセッサ コアには共有キャッシュを使用しないでください。

• ターゲットデバイスにイーサネットベースのフィールドバスを使用している場合は、物理アダプターを使用してください。スイッチアーキテクチャは使用しないでください

• リアルタイム カーネルを使用します。

  重要

  Linux でのリアルタイム操作には、リアルタイム PREEMPT パッチを使用してください。低レイテンシーのカーネルを使用するだけでは不十分です。なぜなら、リアルタイムプロパティの確定性が保証されないからです

  詳細については、以下を参照してください。

  • https://realtime-linux.org/getting-started-with-preempt_rt-guide/

  • https://wiki.linuxfoundation.org/realtime/documentation/technical_basics/start

  以下のシステム設定の多くは、PLCShell を使用してランタイムシステム経由で直接設定することも、ランタイムシステムの設定ファイルから直接設定することもできます。一部のシステム設定は、システムを再起動しても保持されません。設定ファイルに設定を入力すると、ランタイムシステムの起動時に設定が自動的に復元されます。対応する PLCShell コマンドを実行すると、それぞれのエントリも設定ファイルに追加されます

  PLC シェルコマンド	設定ファイルエントリ	ファンクション
  rt-get scaling_governor/kernelinfo/hyperthreading/throttling/napi <device>		システム設定に関する情報を返します 例 3. 例 rt-get scaling_governor 使用可能なスケーリングガバナーを表示し、コアに設定されているスケーリングガバナーを返します
  rt-set scaling_governor <cpu_index> <value>	[CmpLinuxRTDiag] ScalingGovernor.CPU0=performance	特定のコアまたはすべてのコアのスケーリングガバナーを指定されたオプションに設定します 例 4. 例 set scaling_governor all performance
  rt-set hyperthreading <state>	[CmpLinuxRTDiag] Hyperthreading=off	ハイパースレッディングのオン/オフを切り替えます
  rt-set throttling <state>	[CmpLinuxRTDiag] Throttling=off	スロットリングをオン/オフにします
  rt-set napi <device> <state>	[CmpLinuxRTDiag] Napi=eno1	ネットワークアダプタのスレッド NAPI を有効または無効にします
  rt-clear-settings		すべて削除します rt-set 設定ファイルからの設定
  rt-marker-set <taskname> <threshold>	[CmpLinuxRTDiag] TraceMarker.TaskName=MainTask TraceMarker.ThresholdUs=100 [SysTask] Linux.MeasureInterval=1	ジッターが指定された制限を超えたときに、指定されたタスクのカーネルトレースマーカーの書き込みを有効にします。 ランタイムが root ユーザーとして実行されている場合にのみ使用可能
  rt-marker-disable		カーネルトレースマーカーを無効にします
  rt-marker-get		カーネルトレースマーカーとジッター制限に設定されたタスク名を指定します
  irq-list		使用可能なすべての IRQ、その優先順位、およびシステム上のアフィニティを一覧表示します
  irq-set-prio <no | device> <priority>	[CmpLinuxInterrupt] Interrupt.1.Priority=51 Interrupt.1.Device=eno1	Sets the priority of interrupts specified either by number <no> or device <device> to the desired value
  irq-set-affinity <no | device> <bitmask>	[CmpLinuxInterrupt] Interrupt.1.Affinity=128 Interrupt.1.Device=eno1	Sets the core affinity of the interrupt specified either by number <no> or device <device> to the desired bitmask
  irq-clear-settings		すべて削除します irq sets 設定ファイルからの設定

  リアルタイムでの要求には、RT プリエンプトカーネルを使用する必要があります (https://wiki.linuxfoundation.org/realtime/documentation/start) お使いの Linux システム用。Debian ディストリビューションと Ubuntu ディストリビューションの場合は、RT カーネルがパッケージとして用意されており、次のコマンドを使用して簡単にインストールできます apt コマンド。これについての詳細は、お使いのディストリビューションのマニュアルを参照してください。

  • Debian システムの場合

    sudo apt-get install linux-image-rt-amd64

  • を使う uname -a 例えば、どのカーネルを使っているかを確認するコマンド。

• お使いのシステムで Windows マネージャや GUI/X サーバなどを使用しないでください。

  これらのツールを使用すると、システムのリアルタイム機能に影響を及ぼし、IEC アプリケーションで高いジッターが発生する可能性があります。

「rt-tools」の使用:

• 「rt-tools」のインストール: sudo apt install rt-tests

• 「cyclictest」を開始します。 sudo cyclictest -p 99 -t -m

• の man cyclictest コマンドでは、システムのより詳細な、または特定のパフォーマンス側面をより適切に測定するために使用できる、より多くのコマンド ライン オプションが表示されます。

• 必要なリソース、必要なパフォーマンス、プロジェクトサイズの観点から、システムを最適化したいアプリケーションを大まかに説明するテストアプリケーションを作成します。

• これを繰り返し行うことができます。最初に非常に大まかな近似を作成し、それを拡張して実際のアプリケーションにどんどん近づけます。

• 分。ジッタ (μs) / 最大ジッター (μs)

  • 値は、「cycletest」プログラムによって決定された値にできるだけ近い必要があります。詳細はセクションで説明されています Linuxのセットアップ。

  • ジッターと遅延の詳細については、以下を参照してください。 ジッターとレイテンシーの定義

  • [監視] タブの詳細については、次を参照してください。 タブ: モニタリング

• 平均サイクル時間 (μs) / 最大サイクルタイム (μs) サイクルタイム (μs)

  • 最大サイクルは、設定されたサイクル タイムに決して近づいてはなりません。これにより、システムに高負荷がかかるとすぐに問題が発生します。

  • サイクルタイムは常にできるだけ短くしてください。

• 長時間実行されるタスクを複数の小さなタスクに分割します。

• 実行中、最も優先度の高いタスクの最大サイクル タイムは、設定されたサイクル タイムに決して達してはなりません。これを回避できない場合は、設定されたサイクル タイムを増やして、一貫した実行時間を確保する必要があります。

• フィールドバス システム (EtherCAT や PROFINET など) を開始する場合、開始サイクルにより CPU 負荷がわずかに高くなる可能性があります。この場合、アプリケーションの起動直後に CPU 負荷を監視することが合理的です。

次のオプションは変更できません CODESYS Virtual Control SLただし、ホスト上で構成する必要があります。

• の値を設定します DisableCpuDmaLatency 1に:

  [SysCpuHandling]
  Linux.DisableCpuDmaLatency=1

  • これはランタイム バージョン 4.11.0.0 のデフォルト設定であることに注意してください。

  • ランタイムのバージョンを確認するには、 エクストラ → Linuxをアップデートする → システム → システム情報。

• リアルタイムカーネルが実際に使用されていることを確認してください。

  • バージョン 4.11.0.0 では、PLC シェル コマンドを使用できます。 rt-get kernelinfo これを確認するために。

  • 古いバージョンを使用している場合は、コマンドラインでこれを直接テストできます。 uname -a コマンド。

  • リアルタイムカーネルを使用していない場合は、最適化を最初から開始する必要があります。

• 前のステップのテストを使用できます。 の設定 CODESYS ランタイムシステム IEC アプリケーションをテストするため。

• 使用できます マルチコア の特徴 CODESYS。

• タスクの正しい優先順位を決定します。重要なタスクは優先順位を高くする必要があります。

  表 6. IEC タスクの優先順位と Linux スレッドの優先順位のマッピング:

  IEC タスクの優先順位	ランタイム優先度	Linuxの優先順位
  --	0	88 (SCHED_FIFO)
  --	31	57 (SCHED_FIFO)
  0 (最も高いリアルタイム優先度)	32	56 (SCHED_FIFO)
  15 (リアルタイム優先度が最低)	47	41 (SCHED_FIFO)
  16 (リアルタイム優先ではない)	48	0 (SCHED_OTHER)
  31 (リアルタイム優先ではない)	63	0 (SCHED_OTHER)
  --	64	0 (SCHED_OTHER)
  --	255	(SCHEDLE)
  注記 従来の Linux システムでは、ほとんどの割り込み (IRQ) とカーネルワーカーは Linux の優先度が 50 です。それを上回る優先順位 (高負荷) を使用すると、システム機能 (ネットワーク/ストレージ) が期待どおりに動作しなくなる可能性があります

  
  
  

• タスクの優先度は、それぞれのタスク設定で設定できます。

  

ここで説明したすべての手順を実行しても望ましいパフォーマンスが得られない場合は、次のセクションを参照してください。

• フィールドバス固有の情報

• [専門家向け] – 追加のツールとトピック

• チェックしてください Send Time / Recv Time EtherCAT ステータス ページの値。

  • Intel Core i7 プロセッサを搭載した x64 CPU と適切なアダプタでは、10µs 未満になるはずです。

  • チップが統合された ARM プロセッサでは、最大 50µs 以上の時間がかかります。

  

• チェックしてください Send Time / Recv Time PROFINET ステータス ページの値。

  • Intel Core i7 プロセッサを搭載した x64 CPU と適切なアダプタでは、10µs 未満になるはずです。

  • チップが統合された ARM プロセッサでは、最大 50µs 以上の時間がかかります。

  

• 優先順位と必要な IRQ を並べ替えるには、PLC シェル コマンドを使用できます。 irq-list そして irq-set-prio。

  • これらのコマンドは、IEC 優先順位ではなく、通常の Linux 優先順位を使用します。

  • この最適化は次の場合には実行できません。 CODESYS Virtual Control SL、むしろホストシステム上で。

• デバイスには別のネットワーク アダプターを使用してください。

• 詳細については、以下を参照してください。

  • EtherCAT

  • プロフィネット

  • イーサネット/IP

  • CANbus、CANopen

• KernelShark / カーネル トレース

  • パフォーマンスの問題の原因がスケジューリングに関係していることがわかった場合は、このプログラムを選択してください。「カーネルトレース」を使用すると、タスクが別のタスク、別のサービス、または割り込みによって中断されていないかどうかを確認できます

    • trace-cmd record -p function

    • KernelShark を使用して、生成された trace.dat ファイル。

  • 一般に、スケジュールの問題は次の 2 つのカテゴリに分類できます。

    • スーパーセッション/プリエンプション

      • 実行を妨げる割り込みやタスクが不要な場合は、割り込みを禁止してください。

      • 自分のタスクの優先度を上げるか、他のタスクの優先度を下げます。

      • 別の CPU コアに切り替えます。

      重要

      前の章で説明したプログラムを使用して、変更の有効性を確認してください。

    • 実行時間

      以下の「カーネル関数トレース」を参照してください

• カーネル関数トレース

  • コードの処理時間が長すぎる場合は、このツールを使用して問題を見つけることができます。

  • 実行時間が長すぎる関数が独自のコードにある場合は、それを最適化する必要があります。

  • 実行時間が長すぎる関数がカーネル内にある場合は、別のカーネル関数を使用して目的の機能を実現できます。あるいは、実行時間を短縮するために、構成パラメーターをカーネルドライバーに渡すこともできます。

  • これらのオプションのいずれも問題を解決できない場合は、おそらくより強力なハードウェアを使用する必要があります。

次の点を参考にして、パフォーマンス目標を達成するための適切な手段がリストに含まれているかどうかを確認してください。

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• ソフトロックアップなし

• irqbalance の無効化

• kernel.sched_rt_runtime_us